fix(ci): SHA-pin scan-and-report steps so sha_pinning callers can start it - #209
Conversation
…rt it Callers with `sha_pinning_required: true` (e.g. hyperpolymath/echidna) refuse this reusable at startup because its steps used tag refs: The actions actions/checkout@v4.3.1, dtolnay/rust-toolchain@v1, and swatinem/rust-cache@v2.8.2 are not allowed in hyperpolymath/echidna ... A caller's own actions.lock does not cover a cross-repo callee's steps, so the callee must carry commit SHAs itself (same shape as the standards reusables, which start fine under the same policy). #201 had pinned them; #203's `gh actions-lock` rewrite turned them back into tags. - checkout 3d3c42e5 (v7.0.1), rust-toolchain 02cb101e (v1), rust-cache 6323deb1 (v2.9.2); lock entry updated to match by hand (`gh actions-lock` write mode de-pins them again) - `toolchain: v1` -> `stable` (v1 is the action's tag, not a Rust toolchain) - one "managed by gh actions-lock" line after SPDX instead of three Verify (--no-fix) on this file: 0 errors, 3 sha-as-ref warnings; repo total 67 -> 66 findings, none new. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SJGZgoR9ArMgxKcqG7ChW8
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Advanced Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (1)
Included review availability: This review used your included allowance. Your plan provides up to 1 included review per hour; 0 remain after this review. 📜 Recent review details⏰ Context from checks skipped due to timeout. (20)
|
| Layer / File(s) | Summary |
|---|---|
Update workflow header and action pins .github/workflows/scan-and-report.yml |
The workflow header now includes an SPDX identifier and a gh actions-lock management comment. The checkout, Rust toolchain, and Rust cache actions now use pinned commit SHAs with version comments. The Rust toolchain remains set to stable. |
Priority: ➖ Normal
Estimated code review effort: 1 (Trivial) | ~4 minutes
Change: Bug fix
Suggested reviewers: metadatastician
Merge Risk: ⚪ Minimal · up to 153d3
No actionable merge-blocking risk remains from the reviewed changes.
Architecture Summary
Architecture risk: 🔵 Low · up to 153d3
The changed surface does not map to a changed system, dependency edge, entrypoint, or external dependency.
Changed systems: None identified.
Architecture concerns
No architecture-level concerns identified.
Review details
Before / after behavior
- observed — Modified behavior in .github/workflows/scan-and-report.yml: The workflow header now places the SPDX identifier before the
gh actions-lockmanagement comment, replacing the previous repeated management comments. - observed — Modified behavior in .github/workflows/scan-and-report.yml: The checkout, Rust toolchain, and Rust cache action references now use pinned commit SHAs with version comments instead of version tags; the Rust toolchain input remains
stable.
🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
| Check name | Status | Explanation |
|---|---|---|
| Docstring Coverage | ✅ Passed | No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0… |
| Linked Issues check | ✅ Passed | Check skipped because no linked issues were found for this pull request. |
| Out of Scope Changes check | ✅ Passed | Check skipped because no linked issues were found for this pull request. |
| Title check | ✅ Passed | The title clearly and concisely describes the main change: SHA-pinning the reusable scan-and-report workflow so callers with SHA-pinning requirements can start it. |
| Description check | ✅ Passed | The description is directly related to the changeset. It explains the startup failures, the SHA pins, the lockfile updates, the toolchain correction, verification results, and the CodeQL fix. |
✨ Finishing Touches 💡 1
🛠️ Fix failing CI checks 💡
- Commit to this branch
- Create a new PR
- Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Autopilot is currently an internal CodeRabbit preview.
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.
A rabbit checks each action pin,
Then nibbles clover in the sun.
The toolchain stays on stable ground,
Three SHA pins are safely found.
The workflow header gets its mark,
And bunnies bound off through the park.
Comment @coderabbitai help to get the list of available commands.
codeql.yml was bumped to actions/checkout@v7.0.1 and github/codeql-action@v4.38.2 but actions.lock still pinned v6.0.2 and v4.34.0, so every CodeQL run since 5e75753 (2026-09-28) died at startup with "Invalid lockfile". CodeQL is the ruleset's only required status check, so no PR on main could merge. Hand-edited (write mode de-pins SHAs and prunes shared records): v4.38.2 -> 2892aa5e (annotated tag dereferenced), v7.0.1 -> 3d3c42e5. gh actions-lock --no-fix: codeql.yml findings 10 -> 0. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SJGZgoR9ArMgxKcqG7ChW8
…399) ## Why **Security Scan.** echidna sets `sha_pinning_required: true`. The panic-attack reusable it called, at `27b3d93`, had tag-ref steps, so every Security Scan run ended in `startup_failure`. hyperpolymath/panic-attack#209 SHA-pins those steps. It merged as `5ee2565`, a signed and verified commit. This PR moves the callee pin to that commit. `VERISIMDB_PAT` is still `required: false` in the callee. Without the secret, the callee skips the cross-repo dispatch and emits a `::notice::`, so the scan itself can pass. **CodeQL** (second commit). `codeql.yml` uses `github/codeql-action@v4.38.1`, but `actions.lock` still pinned `v4.38.0`. So CodeQL has ended in `startup_failure` on `main` (the 2026-10-01 scheduled run) and on every PR. I re-keyed the entry by hand to the dereferenced tag commit `1c5b6756`. `gh actions-lock` write mode de-pins SHAs, so I did not use it. The same fix restored panic-attack's CodeQL: its run on `5ee2565` concluded `success`. ## Verification `gh actions-lock --no-fix --json`: | | errors | warnings | |---|---|---| | main | 5 | 4 | | this head | 3 | 3 | - The security-scan pin bump changes no finding. The findings are identical before and after it, because the lock does not track job-level reusables. - The 3 errors and 3 warnings left are pre-existing: agda-meta-checker, mvp-smoke and s4-loop. ## Not fixed here (owner action) The Security Scan **dispatch** to `verisimdb-data` needs a valid `VERISIMDB_PAT`. See #310. Refs #310 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01SJGZgoR9ArMgxKcqG7ChW8 ### Pre-existing reds (deferred) These fail identically on `main` (`ba373a8`). Each failing check context is deferred to #401: `Dependency audit` (#401), `governance / Workflow security linter` (#401), `governance / Validate Hypatia Baseline` (#401, #314), `lint-workflows` (#401). On this head, **CodeQL** goes from `startup_failure` to `success`, and the required `scan / gitleaks`, `scan / rust-secrets` and `scan / shell-secrets` all pass. Security Scan runs only on push and schedule, so the callee pin is proved by its first `main` run after merge. --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Why
hyperpolymath/echidnahassha_pinning_required: true. Its Security Scan calls this reusable and has ended instartup_failuresince the pinning rule landed. The run page for echidna run 36185528155 says:actions/checkoutis GitHub-owned, and echidna hasgithub_owned_allowed: true. So the allow-list is not the cause; the tag refs are.A caller's own
actions.lockdoes not cover a cross-repo callee's steps, so the callee has to carry commit SHAs itself.Positive control: echidna's Scorecard and Secret Scanner succeed through
standards/*-reusable.yml@571cc73, whose steps are written@<sha> # vX.#201 had pinned these steps. #203's
gh actions-lockrewrite turned them back into tags.Change
actions/checkout@3d3c42e5(v7.0.1)dtolnay/rust-toolchain@02cb101e(v1)Swatinem/rust-cache@6323deb1(v2.9.2)actions.lockentry by hand to match, becausegh actions-lockwrite mode de-pins the steps again.toolchain: v1tostable.v1is the action's tag, not a Rust toolchain.Verification
gh actions-lock --no-fix --json:sha-as-refwarnings (the same advisory the standards reusables carry).Also: unblocks CodeQL (second commit)
codeql.ymlwas bumped tocheckout@v7.0.1/codeql-action@v4.38.2, but itsactions.lockentry still pinned v6.0.2 / v4.34.0. So every CodeQL run since5e75753died at startup with "Invalid lockfile". CodeQL is main's only required check, so no PR could merge.The second commit re-keys that entry, using commit SHAs resolved from the tags. On this head, CodeQL goes from
startup_failuretosuccess.--no-fixrepo errors go from 64 to 58.Pre-existing reds (deferred)
These contexts are red identically on
main5e75753. This PR introduces none of them. They are deferred to #211:chapel-ci,Dogfood Gate,Dependency Review,bridge-gate,cargo-audit.yml,coverage.yml,release.yml,Governance(Workflow security linter, Actions lockfile verify),Secret Scanner(gitleaks),Rust CI(clippy, fmt).The failing check contexts are each deferred to #211:
scan / gitleaks(#211),rust-ci / Cargo check + clippy + fmt(#211),governance / Workflow security linter(#211),governance / Actions lockfile verify(#211).Follow-up
echidna's
security-scan.ymlhas to bump its callee pin to this merge commit (echidna#310).🤖 Generated with Claude Code
https://claude.ai/code/session_01SJGZgoR9ArMgxKcqG7ChW8